5 private links
- Red Flags of a Toxic Tech Company
- Vague Answers About Work/Life Balance
- Long Hours Are a Badge of Honor
- Suspiciously High Salary for the Title
- Why Do We Ignore Red Flags?
- Justifying Stress With Money
- "It's a Stepping Stone"
- Need to "Prove Our Worth"
- How Can You Overcome The Temptation?
- Make a list of how your relationships would be impacted
- Ask Brave Questions
- Avoid Companies That Resist Transparency
- Listen to Your Gut!
- Write a Catastrophic Story
I have created/used Service Templates myself. "Stamping out a new service" seems apt as an analogy.
I have difficulty associating with chassis as an analogy in this context. But it's not really a scaffolding either. It's common for multiple cars from a company to share the same common platform (an analogy used in platform engineering), but it's not common for them to share the same chassis.
Some of these patterns could also be useful in other applications.
This article is unfortunately published on a cringe-worthy website that's otherwise full of blockchain bullshit, but it is worth reading by every software engineer who isn't working for Big Tech.
Jean Yang articulates well what the rest of us have been trying to say without much success. The context in which a problem is situated is an important factor to be considered while coming up with a suitable solution for it.
The guides are quite good.
Every hyperlink in each guide is also worth reading.
Every organization gets 3 innovation tokens. Every cool new technology you add to your application's tech stack uses up one token. We try to keep our language choices minimal, but somehow don't apply the same principle when it comes to other parts of the tech stack. A lot of our old boring tools can serve more than their primary purpose. You have to read the second page of the manual. Also, the old boring tools fail in predictable ways. New tools fail in unpredictable ways and are much riskier. Their unknown issues are far harder to deal with than the known issues of old boring tools.